The PacketCable standard defines mechanisms via the Network-based Call Signaling (NCS) specification for detecting connections to an E-MTA that have become stale. However, the mechanisms are only defined for use by the Call Management Server (“CMS”). Furthermore, these mechanisms do not always operate in practice, either because of system ‘glitches’ or because a network operator has disabled the feature.
FIG. 1 illustrates a system 2 for providing telephony services, for example, from a plurality of user interface devices 4A-4n. The user device, which may include, for example, E-MTA devices, provide one or more ports to plug a traditional telephone device into. Each port, including its physical and logical aspects, may be referred to as an endpoint. User devices 4 couple to a cable modem termination system (“CMTS”) 6 via a hybrid fiber coaxial network (“HFC”) 8, as may be implemented by a cable services provider, sometimes referred to as a multiple services provider (“MSO”). CMTS 6 typically couples to CMS 10 via an IP network, for example the internet, over a network 12, such as, for example, an Ethernet protocol network. The dashed lines between CMS 10 and user devices represent a logical connection but not necessarily a physical connection. This logical connection passes messages over HFC 8 and IP network 12 so that CMS 10 and user devices 4 are essentially in communication.
A “stale” connection is defined as a connection that remains to an endpoint of an E-MTA after the user has gone on-hook and no longer serves a useful purpose. Even though a user has ‘hung up’ a telephony by placing the handset on hook or by, for example, pressing an ‘off’ button on an electronic (typically cordless) telephone, when the telephony device is coupled to a user device, such as, for example, a media terminal adaptor (“MTA”) or E-MTA (“embedded MTA”) may still maintain a connection between itself and a CMTS. A management network device, for example a CMS, may receive information that a telephony device coupled to an MTA or E-MTA (for purposes herein, MTA and E-MTA are used interchangeably) is in an on-hook condition and then issue a message to the E-MTA and the CMTS that the connection is deleted. When the E-MTA and the CMTS receive their respective messages that the connection is deleted, the resources, i.e., bandwidth, that were previously allocated for the call are released for use by other applications and/or other user devices.
However, occasionally, the CMS does not properly process the information that the telephony device is on-hook, and thus fails to instruct the CMTS to delete the connection. This may occur due to a ‘bug’ or ‘glitch’ in the operating software of the CMTS or E-MTA device. The CMS may also fail to delete the connection if it is programmed to maintain a connection a certain amount of time after an on-hook condition m case a just-terminated call was a 911 call or call to a similar emergency/safety-related endpoint. Although the CMS may be programmed to instruct the CMTS and E-MTA to delete the call and release resources, for a variety of reasons the CMS may not generate and send an instruction to do so. Since the CMS is typically not directly coupled to ac given E-MTA, and the E-MTA is where a user causes an on-hook condition, the CMS lose track of the need to delete the call because it is involved in other network operations, it loses power or is other wise prevented from performing its functions, or, as discussed above, an error in the software occurs.
Therefore, there is a need for a method for detecting and removing at a user device user device, a stale connection to an E-MTA.